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Abstract of DE1 9924461 

The aim of the invention is to provide a numerical 
control of a machine tool that is easy to 
maintenance and update while being controlled 
by increasingly complex programs. To this end, 
the programs for numerical controls have 
increasingly object-oriented structures. According 
to said structure, applications (10), processes (1 1 
to 13), threads (14 to 17) and modules (18 to 21) 
are represented by respective objects (10 to 21). 
When the numerical control is run up, those 
objects (10 to 17) are produced and in turn 
produce further objects (1 1 to 21 ), every object 
(1 0 to 21 ) assuming a number of defined states. 
Specifically, every object (10 to 17) initiates in all 
objects (1 1 to 21 ) produced by it the initialization 
function realized for said state by the respective 
object (10 to 21) and assumes the next defined 
state only if the object itself and all objects (10 to 
21) produced by it have completed ail functions. 
This state is reported to the producer object (10 
to 17) until the feedback reaches the application 
object (10). The application object (10) itself 
assumes said state and initiates the next step of 
the run-up or terminates the run-up once the last 
step of the run-up has been completed. 
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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

(§) Verfahren zum synchronisierten Hochlauf einer Steuerung 

(§) Urn bei einer zunehmenden Komplexitat der Program- 
me fur numerische Steuerungen fur Werkzeugmaschinen 
eine einfache Wartbarkeit und Erweiterbarkeit sicherzu- 
stellen, weisen die Programme fur numerische Steuerun- 
gen zunehmend eine objektorientierte Struktur auf. Dabei 
werden Applikationen, Prozesse, Threads und Module je- 
weils durch ein Objekt reprasentiert. Bei einem Hochlauf 
werden zunachst diejenigen Objekte erzeugt, die weitere 
Objekte erzeugen, und es nimmt jedes Objekt eine Anzahl 
definierter Zustande an. Insbesondere startet jedes Ob- 
jekt bei alien von ihm erzeugten Objekten die fur diesen 
Zustand durch das jeweilige Objekt realisierte Initialisie- 
rungsfunktion und nimmt den nachsten definierten Zu- 
stand dann an, wenn es selbst und alle von ihm erzeugten 
Objekte samtliche Funktionen vollstandig ausgefuhrt ha- 
ben. Dieser Zustand wird an das erzeugende Objekt ge- 
meldet, bis diese Ruckmeldung beim Applikationsobjekt 
eintrifft. Das Applikationsobjekt nimmt dann selbst die- 
| sen Zustand an und lost den nachsten Schritt des Hoch- 
laufs aus bzw. beendet den Hochlauf, nachdem der letzte 
Schritt des Hochlaufs ausgefuhrt wurde. 
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Beschreibung 

Die Erfindung betrifft ein Verfahren zum synchronisierten 
Hochlauf einer Steuerung nach dern Oberbegriff des An- 
spruchs 1. 

Die EP 0524 344 Bl offenbart eine konfigurierbare 
Werkzeugmaschinensteuerung, die aus mehreren aufgaben- 
orientierten Einheiten besteht, beispielsweise einem numeri- 
schen und einem speicherprogrammierbaren Steuerteil, ei- 
ner Bedienereinheit und einem Kommunikationsbereich mit 
Netzwerkschnittstelle. Weiterhin ist mindestens ein in Soft- 
oder in Soft- und Hardware realisiertes Funktionsobjekt, das 
eine Funktion durchfuhren kann vorgesehen. Dieses Funkti- 
onsobjekt untergliedert sich in einen Prozedurteil, einen 
Kommunikationsteil und evtl. einen Bedienteil. Zusatzlich 
ist mindestens ein Objektmanagcr vorhanden, der minde- 
stens zwei Funktionsobjekte verwaltet, insbesondere deren 
Nachrichtenaustausch synchronisiert. Diese Steuerungs- 
struktur wird auf mindestens einer Datenverarbeitungsan- 
lage realisiert, welche die Daten der Funktionsobjekte und 
Objektmanager bearbeitet und selbst als aufgabenorientierte 
Einheit ausgebildet ist. 

Aus der EP 0 524 344 Bl ist kein systematisches Verfah- 
ren zum Starten einer objektorientiert realisierten Steuerung 
bekannt. 

Aus der EP 0 657 043 Bl ist eine objektorientierte Steue- 
rung fur Werkzeugmaschinen bekannt, bei der aus Objekt- 
klassen eine Reihe von Objekten gebildet werden. Ausge- 
hend von der in der EP 0 524 344 Bl offenbarten Struktur 
einer Steuerung werden in der EP 0 657 043 Bl die konkret 
erforderlichen Objektklassen und Objekte offenbart, die er- 
forderlich sind, um eine herkommliche Funktionalitat einer 
Steuerung zu realisieren. Dazu gehbren beispielsweise Ob- 
jektklassen fur Bearbeitungs-, Geometrie, Kinematik- und 
Technologiedatentypen ebenso wie Steuerdatentypen und 
eine Objektklasse Ablauf steuerung. Von jeder Objektklasse 
kann eine beliebige Anzahl Objekte gebildet werden, die je- 
weils einen eigenen Datenbereich, einen Botschaftenmecha- 
nismus zur Kommunikation mit anderen Objekten und einen 
Prozedurteil zur Ausfuhrung von Methoden zur Bearbei- 
tung, Kinematik, Geometrie oder Technologie beinhalten. 
Durch die Ablaufsteuerung werden die Benutzereingaben 
interpretiert und fiihren zur Aktivierung der ausgewahlten 
Objekte. Die ausgewahlten Objekte kommunizieren unter- 
einander und bilden durch diese netzwerkartige Verknup- 
fung eine ablauffahige Funktionseinheit der Steuerung. 

Auch aus der EP 0 657 043 Bl ist kein systematisches 
Verfahren zum Starten einer objektorientiert realisierten 
Steuerung bekannt. 

Aus der EP 0 717 866 B 1 ist ein CNC-Steuerungssystem 
bekannt, das ein objektorientiertes Programm beinhaltet, in 
weichem Objekte objektorientierte Nachrichten austau- 
schen. Im objektorientierten Programm sind die Objekte in 
Klassen unterteilt, beispielsweise eine Prozessklasse, die 
Objekte fur Bearbeitungsprozesse wie Bohren, Gewinde- 
schneiden, Raumen usw. beinhaltet, die durch Maschinen- 
komponenten ausgefuhrt werden. Dabei beinhaltet eine 
Klasse immer ahnliche Objekte, das heisst Objekte, die in 
ihrer Grundstruktur iibereinstimmen. Aufgrund der einheit- 
lichen Grundstruktur der Objekte einer Klasse besteht die 
Moglichkeit, dass beim Erstellen neuer Objekte ausge- 
wahlte Eigenschaften der jeweiligen Klasse an das neue Ob- 
jekt vererbt werden. Beispielsweise weist ein Bohr-Objekt 
eine Tiefe und einen Durchmesser auf, die von einem ande- 
ren Objekt der Prozessklasse geerbt werden konnen, bei- 
spielsweise einem Gewindeschneid-Objekt, das ebenfalls 
eine Tiefe und einen Durchmesser aufweisL Eine weitere 
Objektklasse weist Maschinenkomponenten, wie beispiels- 
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weise eine Spindel, Achsen, einen Drehtisch usw., auf. Wei- 
terhin sind Objektklassen fur das Kernel mit einem Motion 
und einem Logic Controller als Objekte, fur Plattform Ser- 
vices, das Operating System und die Device Driver vorgese- 

5 hen. Im Betrieb der Steuerung ist es erforderlich, dass Nach- 
richten zwischen den einzelnen Objekten ausgetauscht wer- 
den. Fur einen Bohrvorgang wird beispielsweise vom Bohr- 
Objekt eine Nachricht die Drehzahl des Bohrers betreffend 
an das Objekt Spindel ubertragen, weiterhin werden Nach- 

10 richten die Position des Loches betreffend an die Objekte 
der beteiligten Achsen ubertragen usw.. Dabei ist ein Stan- 
dard-Interface fur die Nachrichten vorgesehen, damit diese 
einen universellen Aufbau aufweisen und unabhangig von 
den beteiligten Objekten ausgestaltet werden konnen. Diese 

15 Standard-Schnittstelle zum Nachrichtenaustausch zwischen 
Objekten wird bei einem Objekt, das Nachrichten bezuglich 
der Bewegung empfangt oder sendet durch einen Software- 
kern realisiert, der in Echtzeit arbeiten soli und Nachrichten 
empfangt und sendet. 

20 Ein Verfahren fur einen synchronisierten Hochlauf einer 
objektorientierten Steuerung wird dabei nicht offenbart. 

Aufgabe der vorliegenden Erfindung ist es daher, ein Ver- 
fahren fur einen Start einer Applikation einer numerischen 
Steuerung anzugeben, bei dem synchronisiert deren Pro- 

25 zesse, Threads und Module in eine Struktur eingebunden 
und initialisiert werden und bei dem anschliessend in den 
Normalbetrieb ubergegangen wird. Es soil sichergestellt 
werden, dass beim Ubergang in den Normalbetrieb insbe- 
sondere die Kommunikationskanale vorhanden sind, uber 

30 die Module miteinander kommunizieren, die zu unter- 
schiedlichen Threads oder Prozessen gehoren. 

Diese Aufgabe wird durch ein Verfahren mit den im An- 
spruch 1 angegebenen Merkmalen gelost. 
Weiterbildungen und vorteilhafte Ausgestaltungen des er- 

35 findungsgemassen Verfahrens sind den abhangigen Ansprii- 
chen zu entnehmen. 

Das erfindungsgemasse Verfahren weist den Vorteil auf, 
dass die Software einer Steuerung fur eine Werkzeugma- 
schine in Form einer Applikation nut den zugehbrigen Pro- 

40 zessen, Threads und Modulen bis zur Betriebsbereitschaft 
der Steuerung synchronisiert gestartet wird. Dabei wird in 
einem ersten Initialisierungsschritt die Applikation in Form 
einer oder mehrerer ausfuhrbarer Dateien in den Arbeits- 
speicher geladen und es werden die einzelnen Objekte, wie 

45 beispielsweise Prozesse, Threads und Module erzeugt. So- 
bald alle Objekte erzeugt wurden, werden in einem zweiten 
Initialisierungsschritt die Objekte initialisiert, beispiels- 
weise mit Parameterwerten. Sobald dieser Initialisierungs- 
schritt abgeschlossen ist, konnen weitere Initialisierungs- 

50 schritte folgen, bis in einem letzten Initialisierungsschritt 
die gesamte Applikation fur den Betrieb freigegeben wird. 
Sornit sind bei einem fehlerfreien Hochlauf alle Applikatio- 
nen, Prozesse, Threads und Module erzeugt, initialisiert und 
die Steuerung ist betriebsbereit. Soilten Fehler in einem Ob- 

55 jekt auftreten, ist nach einem derartigen synchronisierten 
Hochlauf bekannt, welche Prozesse, Threads oder Module 
fehlerhaft sind. Ein weiterer Vorteil besteht darin, dass dem 
Anwender gemeldet wird, falls dies fur eine benotigte App- 
likation, einen Prozess, einen Thread oder ein Modul nicht 

60 der Fall sein sollte. 

Die Erfindung wird im folgenden anhand der in der 
Zeichnung dargestellten Ausfuhrungsformen naher erlau- 
tert. Die Figur zeigt: 
Fig. 1 eine mogliche schaltungstechnische Realisierungs- 

65 form einer erfindungsgemassen Steuerung, 

Fig. 2 eine mogliche Struktur einer objektorientierten 
Applikation. Die Erfindung soli im folgenden anhand einer 
einfachen numerischen Steuerung fur eine Werkzeugma- 
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schine erlautert werden. 

Die Steuerungsanordnung weist mindestens einen Mas- 
senspeicher 1 auf, der iiber einen bidirektionalen Bus 2 mit 
einem Prozessor 3 verbunden ist. Dadurch kann der Prozes- 
sor 2 schreibend und lesend auf den Massenspeicher 1 zu- 5 
greifen. Der Massenspeicher 1 kann durch einen magne- 
tischen oder optischen Speicher oder eine Kombination 
mehrerer unterschiedlicher Speicher realisiert werden. Wei- 
terhin kann der Massenspeicher 1 auswechselbare Speicher- 
medien, wie beispielsweise Compakt Disks, aufweisen. 10 
Uber den Bus 2 besteht auch eine bidirektionale Verbindung 
mit einem Arbeitsspeicher 4, der als Schreib-/Lesespeicher 
ausgestaltet ist und eine kiirzere Zugriffszeit als der Massen- 
speicher 1 aufweist. Der Arbeitsspeicher 4 kann - zumindest 
teilweise - auch in den Prozessor 3 integriert ausgefuhrt 15 
sein. Uber den Bus 2 besteht weiterhin eine bidirektionale 
Verbindung zu einem Festwertspeicher 5, der im Unter- 
schied zum Arbeitsspeicher 4 nur eine kleine Speicherkapa- 
zitat aufweist und als Lese-Speicher ausgestaltet ist. An den 
Bus ist ausserdem eine Reglerbaugruppe 6 angeschlossen, 20 
mit der wiederum die Antriebsmotoren fiir die Achsen und 
die Spindel verbunden sind. 

Damit der Prozessor 2 der Steuerungsanordnung die ver- 
schiedenen Funktionen der Werkzeugmaschine steuern 
kann, muss die Software fiir die Werkzeugmaschine, die im 25 
folgenden mit Applikation bezeichnet und vom Prozessor 2 
abgearbeitet wird, im Arbeitsspeicher 4 bereitgestellt wer- 
den. Da der Arbeitsspeicher 4 in der Regel kein permanenter 
Speicher ist, wird auf dem Massenspeicher 1 eine ausfuhr- 
bare Datei gespeichert, die ein Erzeugen der gesamten App- 30 
likation im Arbeitsspeicher 4 durch den Prozessor 2 errnog- 
licht, sobald die Steuerungsanordnung mit der Versorgungs- 
spannung verbunden wird. Die Erzeugung der Applikation 
aus der im Massenspeicher 1 gespeicherten Datei wird im 
folgenden als Initialisierung bezeichnet, die meist in mehre- 35 
ren Schritten erfolgt. 

Zu Beginn der Initialisierung wird die Struktur der Appli- 
kation erzeugt. Dabei werden die Daten der mindestens ei- 
nen auf dem Massenspeicher 1 gespeicherten und zur App- 
likation gehorenden ausfuhrbaren Datei in den Arbeitsspei- 40 
cher 4 ubertragen und abgearbeitet. Bei der Abarbeitung 
werden miteinander verkniipfte Objekte erzeugt. Die einzel- 
nen Objekte konnen Kontext sein, wie beispielsweise Thre- 
ads, Kommunikationskanale, globale Speicher, oder es kon- 
nen Datenstrukturen sein, wie beispielsweise Objekte einer 45 
objektorientierten Struktur. 

Eine Applikation wird in mehrere Prozesse untergliedert, 
wobei vorteilhaft jeder Prozess einen eigenen Adressraum 
im Arbeitsspeicher 4 besitzt. Es konnen sich aber auch meh- 
rere oder alle Prozesse einen gemeinsamen Adressraum tei- 50 
len. Jeder Prozess wird in Threads untergliedert und weist 
mindestens einen Unread auf. Der innerhalb eines Threads 
abgearbeitete Code ist in Module unterteilt, zu denen je eine 
definierte Datenstruktur gehort und in denen je mindestens 
eine konkrete Funktion der Steuerung realisiert ist, z. B. 55 
eine Tasche frasen oder ein Gewinde schneiden usw. Die zur 
Applikation gehorenden Module, Threads und Prozesse sind 
derail miteinander verkniipft, dass sie auch uber die Gren- 
zen von Threads und Prozessen hinweg Daten austauschen 
konnen. 60 

Urn eine derartige Struktur der Applikation besonders 
einfach programmtechnisch zu realisieren, wird vorteilhaft 
eine objektorientierte Programmiersprache gewahlt Mittels 
der objektorientierten Programmiersprache wind die Appli- 
kation, jeder Prozess, jeder TTiread und jedes Modul als ein 65 
Objekt ausgestaltet. Die Objekte konnen synchronisiert wer- 
den, weitere Objekt erzeugen und die erzeugten Objekte 
verwalten. Eine derartige Struktur und die genannten Funk- 
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tionen konnen prinzipiell auch durch eine nicht objektorien- 
tierte Programmiersprache realisiert werden. 

Wird die Steuerungsanordnung mit der Versorgungsspan- 
nung verbunden, wird zunachst deren Betriebssystem-Soft- 
ware in den Arbeitsspeicher 4 der Steuerungsanordnung ge- 
laden und anschliessend das Startprogramm der Applika- 
tion. Dieses Startprogramm wird anschliessend ausgefuhrt 
und steuert die synchronisierte Erzeugung zumindest der 
weiteren Prozesse. Alternativ kann durch das Startpro- 
gramm auch die Erzeugung der gesamten Struktur gesteuert 
werden. 

Die vom Startprogramm benotigten Daten sind in einer 
separaten, einzulesenden Datei oder unmittelbar im Start- 
programm selbst gespeichert. Falls diese Daten in einer se- 
paraten Datei gespeichert sind, ladt das Startprogramm auch 
diese Datei in den Arbeitsspeicher 4 und wertet sie aus. Die 
Daten bezeichnen mindestens eine auf dem Massenspeicher 
1 gespeicherte, zu ladende ausfuhrbare Datei, fur einen Pro- 
zeB, der Applikation und optional Ubergabeparameter der 
Prozesse, Informationen zur Synchronisation der Prozesse 
und Informauonen iiber die bei der Initialisierung durchzu- 
fuhrenden Initialisierungs-Schritte. Diese derart definierten 
ausfuhrbaren Dateien werden durch das Startprogramm in 
den Arbeitsspeicher 4 der Steuerung geladen und ausgewer- 
tet. Anschliessend konnen die Prozesse erzeugt werden. 

Beim Abarbeiten des Startprogramms fur den synchroni- 
sierten Hochlauf der Steuerung werden also nacheinander 
fur jede Applikation die benotigten Dateien in den Arbeits- 
speicher 4 geladen. Danach werden die Prozesse, die die 
Applikation bilden, erzeugt, anschliessend die Threads und 
letztendlich die zu den Modulen gehorenden Datenstruktu- 
ren. Dabei werden fiir die Erzeugung der zu jedem Prozess 
gehorenden Threads und der zu jedem Thread gehorenden 
Module weitere Daten benotigt. Die Daten zur Erzeugung 
der Threads konnen im Startprogramm, bzw. einer vom 
Startprogramm eingelesenen Datei, in einer ausfuhrbaren 
Datei des Prozesses oder in einer jeweils eingelesenen Datei 
gespeichert sein. 

SinngemaB gilt das auch fur die Module. Auch hier kon- 
nen die fur die Erzeugung benotigten Daten bereits im Start- 
programm, bzw. in einer vom Startprogramm geladenen Da- 
tei, oder in einer ausfuhrbaren Datei oder einer eigenen Da- 
tei gespeichert sein. Der zum jeweiligen Modul gehorende 
Thread erzeugt aufgrund der Daten iiber ein Modul dieses 
Modul. 

Dadurch entsteht eine baumartige Struktur der Objekte, 
an deren Spitze die Applikation auf der hochsten Hierar- 
chie-Ebene steht. Die Applikation untergliedert sich in Pro- 
zesse, welche wiederum aus Threads bestehen. Auf der un- 
tersten Hierarchie-Ebene stehen die Module, die den Thre- 
ads zugeordnet sind. 

Die Verknupfung zwischen den Modulen, Threads und 
Prozessen bis hin zur Applikation wird durch Kommunika- 
tionskanale realisiert. Da die Module jeweils eine besummte 
Funktionalitat aufweisen, werden fiir jedes Modul definierte 
Kommunikationskanale benotigt, iiber die Daten von oder 
zu einem anderen Modul iibertragen werden. Dies gilt ent- 
sprechend auch fur die Kommunikationskanale zwischen 
Threads und Prozessen. 

In einer erfindungsgemassen Ausgestaltung weist jedes 
Objekt unter anderem einen Programmteil auf, der der In- 
itialisierung dieses Objekts dient und fur jedes Objekt indi- 
viduelle Massnahmen zu dessen Initialisierung ausfuhrL 
Diese individuellen Massnahmen bestehen zumindest darin, 
dass das Objekt bei den ihm hierarchisch untergeordneten 
Objekten die Initialisierung veranlasst, auf die Ausfiih- 
rungsmeldungen aller untergeordneter Objekte wartet und 
dann an das iibergeordnete Objekt, nach eigener korrekter 



DE 199 24 461 A 1 

5 6 



Initialisierung, eine Ausfuhrungsmeldung weiterleitet. Zu- 
satzlich konnen durch den Programmteil zur Initialisierung 
weitere Initialisierungsmassnahmen erfolgen. 

Mittels einer objektorientierten Programmiersprache 
kann diese Zuordnung von Programmteilen besonders vor- 
teilhaft realisiert werden. 

Sob aid ein Modul korrekt erzeugt wurde und sich als Mo- 
dulobjekt in die objektorientierte Struktur eingefiigt hat, 
sendet das Modulobjekt an das ihm hierarchisch ubergeord- 
nete Thrcadobjekt, das das Modulobjekt erzeugt hat, eine 
Ausfuhrungsmeldung zuriick. Daran erkennt das Thrcadob- 
jekt, dass das Modulobjekt fehlerfrei erzeugt wurde. Sobald 
das Threadobjekt von jedem von ihm erzeugten Modulob- 
jekt die Ausfuhrungsmeldung erhalten hat und das Thread- 
objekt auch selbst korrekt erzeugt wurde, sendet es an das 
ihm ubergeordnete Prozessobjekt ebenfalls eine Ausfuh- 
rungsmeldung. Sobald wiederum jedes Prozessobjekt von 
alien von ihm erzeugten Threadobjekten eine Ausfuhrungs- 
meldung zur korrekten Erzeugung empfangen hat und das 
Prozessobjekt auch selbst korrekt erzeugt wurde, sendet das 
Prozessobjekt eine Ausfuhrungsmeldung an das ubergeord- 
nete Applikationsobjekt. 

Sobald das Applikationsobjekt von alien von ihm erzeug- 
ten Prozessobjekten aufgrund der empfangenen Ausfuh- 
rungsmeldungen eine korrekte Erzeugung erkannt hat, er- 
folgt der nachste Schritt der Initialisierung. Bis dahin mus- 
sen alle bereits erzeugten Objekte warten, damit keine Uber- 
schneidungen bei der Initialisierung auftreten, beispiels- 
weise dass ein erstes Objekt mit einem zweiten Objekt kom- 
munizieren will, obwohl das zweite Objekt noch nicht er- 
zeugt wurde. Durch dieses Warten wird die Synchronisation 
der Initialisierung erreicht, da alle Objekte zu einem dcfi- 
nierten Zeitpunkt einen definierten Zustand aufweisen. In 
einem typischen Multitasking Betriebssystem stehen zur 
Realisierung dieses Wartens bzw. dieser Synchronisation 
Mechanismen wie Semaphoren und Barrieren o. a. zur Ver- 
fiigung. 

In einem zweiten Schritt der Initialisierung werden die 
Kommunikationskanale zwischen den Objekten eingerich- 
tet. Indem die Ausfuhrung des im jeweiligen Prozessobjekt 
zur Initialisierung der Kommunikationskanale vorgesehe- 
nen Programmteils veranlasst wird, werden die Kommuni- 
kationskanale eines Prozessobjekts eingerichtet Dies setzt 
sich entsprechend der bei der Erzeugung der Struktur bereits 
beschriebenen Vorgehensweise auch fur Threads und Mo- 
dule fort, bis alle Module ihre Kommunikadonskanale er- 
zeugt haben. 

Nach erfolgreicher Erzeugung aller Kommunikadonska- 
nale durch ein Modulobjekt sendet dieses eine Ausfuhrungs- 
meldung an den veranlassenden Thread zuriick. Sobald ein 
Thread von alien zugeordneten Modulobjekten die Ausfuh- 
rungsmeldung erhalten hat und auch selbst alle Kommuni- 
kationskanale erfolgreich erzeugt hat, sendet der Thread 
ebenfalls eine Ausfuhrungsmeldung an das ubergeordneten 
Prozessobjekt. Hat ein Prozessobjekt von alien zugeordne- 
ten Threads eine Ausfuhrungsmeldung empfangen, und 
auch selbst alle Kommunikadonskanale korrekt erzeugt, 
sendet es eine Ausfuhrungsmeldung an das ubergeordnete 
Applikationsobjekt. Sobald das Applikationsobjekt von al- 
ien zugeordneten Prozessobjekten eine Ausfuhrungsmel- 
dung erhalten hat, ist auch dieser zweite Schritt der Initiali- 
sierung abgeschlossen. 

Da beim Betrieb der Steuerung zwischen den Objekten 
die unterschiedlichsten Daten moglichst schnell ausge- 
tauscht werden miissen, werden die Kommunikationskanale 
unterschiedlich realisiert. Beispielsweise kann ein Kommu- 
nikationskana! zwischen zwei Modulobjekten desselben 
Threads in Form eines fur beide Modulobjekte gemeinsa- 



men Speichers realisiert werden, iiber den Daten ausge- 
tauscht werden; ein Kommunikationskanal zwischen Modu- 
len in verschicdenen Prozessen muB Daten von einem 
Adressraum in einen anderen iibertragen konnen. 

5 Es besteht die Mbglichkeit weitere Initialisierungsschritte 
durchzufuhren, die prinzipiell idendsch zu den bisher be- 
schriebenen ablaufen. Es wird immer von den hierarchisch 
ubergeordneten Objekten die Ausfuhrung eines Programm- 
teils zur Erzeugung einer bestimmten Funktion ausgelost 

10 und anschliessend gewartet, bis von alien untergeordneten 
Objekten eine Ausfuhrungsmeldung empfangen wurde, be- 
voreine Ausfuhrungsmeldung an ein ubergeordnetes Objekt 
gesendet wird. Erst nachdem von dem Applikationsobjekt 
die Ausfuhrungsmeldungen aller zugeordneten Prozessob- 

15 jekte empfangen wurden, erfolgt der nachste Schritt der In- 
itialisierung. Dadurch wird sichergestellt, dass die Initiali- 
sierung synchron erfolgt und alle Objekt zu einem bestimm- 
ten Zeitpunkt einen definierten Zustand einnehmen. 
In diesen weiteren Iniualisierungsschritten konnen bei- 

20 spielsweise Parameter an einzelne Objekt ubergeben wer- 
den. Die prinzipielle Vorgehensweise erfolgt wie bereits fiir 
den vorhergehenden Initialisierungsschritt beschrieben. 

Als letzter Inidalisierungsschritt erfolgt das Starten der 
Applikadon. Dabei wird jedem Objekt signalisiert, dass die 

25 Initialisierung abgeschlossen wurde und von nun an der re- 
gulare Betrieb der Steuerung beginnt. Dadurch erkennt ein 
Objekt, dass es die reguiare Bearbeitung von iiber die Kom- 
munikationskanale empfangenen Daten durchfuhren soli. 
Bei diesem letzten Schritt ist keine Ausfuhrungsmeldung 

30 zum ubergeordneten Objekt mehr zwingend erforderlich, da 
die korrekte Initialisierung bereits durch die vorhergehen- 
den Ausfuhrungsmeldungen signalisiert wurde und die zur 
Initialisierung erforderliche Synchronic nicht mehr beno- 
tigt wird. 

35 Ein einfaches Beispiel fur eine Initialisierung ist in Fig. 2 
dargestellt. Dabei wird zunachst das Ladeprogramm zum 
Laden des Startprogramms ausgefuhrt, so dass sich das 
Startprogramm im Arbeitsspeicher 4 befindet. Falls die Da- 
ten nicht bereits im Startprogramm enthalten sind, wird an- 

40 schliessend durch das Startprogramm eine Datei geladen, 
die Informationen iiber die programmtechnische Struktur 
der gesamten Applikation und iiber eine oder mehrere Da- 
teien beinhaltet, in der die gesamte Applikation auf dem 
Massenspeicher 1 abgelegt ist und die alle Daten fur die ge- 

45 samte zu initialisierende Applikation beinhaltet. Diese In- 
formation wird durch das Startprogramm derail benutzt, 
dass alle Dateien, die Informationen zur Applikation bein- 
halten, in den Arbeitsspeicher 4 geladen werden und das 
Applikationsobjekt 10 durch das Startprogramm erzeugt 

50 wird. 

Dem derart erzeugten Applikationsobjekt 10 ist bekannt, 
dass die Prozesse 11, 12 und 13 dem Applikationsobjekt 10 
zugeordnet sind. Daher werden durch das Applikationsob- 
jekt 10 die Prozesse 11, 12 und 13 in der objektorientierten 

55 Struktur erzeugt. Dies geschieht dadurch, dass das Applika- 
tionsobjekt mindestens eine ausfuhrbare Datei in den Ar- 
beitsspeicher 4 ladt, und die Ausfuhrung dieser mindestens 
einen Datei startet Dadurch werden alle Prozessobjekte U, 
12 und 13 erzeugt. 

60 Die neu erzeugten Prozessobjekte 11, 12 und 13 beinhal- 
ten Informationen dariiber, welche Threads dem jeweiligen 
Prozessobjekt 11, 12 und 13 zugeordnet sind, so dass die Er- 
zeugung der Threads 14, 15, 16 und 17 durch die Prozessob- 
jekte 11-13 veranlasst wird. 

65 Die Threadobjekte 14-17 beinhalten wiederum Informa- 
tionen dariiber, ob ihnen weitere Module zugeordnet sind. 
Dadurch werden die Modulobjekte 18-21 erzeugt Die Mo- 
dulobjekte 18-21 bilden die unterste Hierarchieebene der 
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Steuerungssoftware fur die Werkzeugmaschine, so dass sie 
keine weitere Information uber zugeordnete Objekte bein- 
halten. 

In jedem Objekt ist gespeichert, welche weiteren Objekle 
ihm zugeordnet sind, beispielsweise ist im Applikauonsob- 
jekt 10 gespeichert, dass ihm die Prozessobjekte 11, 12 und 
13 zugeordnet sind, im Prozessobjekl 11 ist gespeichert, 
dass ihm die Threadobjekte 14 und 15 zugeordnet sind usw. 
Weiterhin ist in jedem Objekt gespeichert, von welchem Ob- 
jekt es crzeugt worden ist, das heisst in den beiden Thread- 
objekten 14 und 15 ist gespeichert, dass sie von dem Pro- 
zessobjekt 11 erzeugt worden sind. Ausnahmen bilden das 
Applikationsobjekt 10, in dem nicht gespeichert ist, von 
welchem Objekt es erzeugt worden ist, und die Modulob- 
jekte 18-21, denen keine weiteren Objekte zugeordnet sind. 

Nachdem somit die gesamte Software der Steuerung syn- 
chronisiert erzeugt wurde, erfolgt noch eine Ausfuhrungs- 
meldung durch die erzeugten Objekte an die Objekte, die sie 
erzeugt haben, iibcr ihre erfolgreiche Erzeugung. Dies be- 
ginnt mit den zuletzt erzeugten Modulobjekten 18-21, die 
nach einer erfolgreichen Erzeugung an die ihnen ubergeord- 
neten Threadobjekte 14-17, von denen sie erzeugt wurden, 
eine Ausfuhrungsmeldung iibertragen. Diese Ausfuhrungs- 
meldung signalisiert jedem der Threadobjekte 14-17 die er- 
folgreiche Erzeugung der von ihm erzeugten Modulobjekte 
18-21 und wird von diesem nur ubertragen wenn die Erzeu- 
gung der Modulobjekte 18-21 wirklich erfolgreich war. 

Hat ein Threadobjekt die Ausfiihrungsmeldung uber die 
erfolgreiche Erzeugung aller ihm zugeordneten Modulob- 
jekte empfangen und wurde auch selbst fehlerfrei erzeugt, 
sendet es ebenfalls eine Ausfiihrungsmeldung, dass die Er- 
zeugung erfolgreich abgeschlossen wurde an das Prozessob- 
jekl, das den Threadobjekt erzeugt hat. Das bedeutet, dass 
die Threadobjekte 14 und 15 die Ausfiihrungsmeldung an 
Prozessobjekt 11 senden, welches darauf bereits wartet. So- 
bald Prozessobjekt 11 von den von ihm erzeugten Threadob- 
jekten 14 und 15 eine abgeschlossene Erzeugung gemeldete 
wurde, meldet auch Prozessobjekt 11 an das Applikations- 
objekt 10 eine abgeschlossene Erzeugung. Ebenso meldet 
Threadobjekt 17 eine abgeschlossene Erzeugung an Pro- 
zessobjekt 13, das danach wiederum eine abgeschlossene 
Erzeugung an das Applikationsobjekt 10 meldet. 

Nachdem dem Applikationsobjekt 10 durch alle von ihm 
erzeugten Prozessobjekte 11, 12 und 13 eine abgeschlossene 
Erzeugung der Struktur gemeldet wurde, steht die durch das 
Applikationsobjekt 10 realisierte Struktur in der Steuerung 
zur Verfiigung. Der erste Schritt des synchronisierten Hoch- 
laufs der Steuerung ist damit abgeschlossen. 

Kann ein Objekt nicht erzeugt werden, so dass eine Sto- 
ning vorliegt, sendet dieses Objekt keine Ruckmeldung, 
dass die Erzeugung erfolgreich abgeschlossen wurde. Das 
hierarchisch ubergeordnete Objekt stellt nach einer gewis- 
sen Wartezeit fest, dass der Hochlauf nicht erfolgreich 
durchgefuhrt werden konnte und sendet ebenfalls keine 
Ausfiihrungsmeldung an das ihm ubergeordnete Objekt. Die 
entsprechende Funktion steht dann in der Applikation nicht 
zur Verfiigung. Aufgrund der in den jeweils iibergeordneten 
Objekten nicht empfangenen Ausfuhrungsmeldung kann er- 
mittelt werden, an welcher S telle eine Erzeugung nicht mog- 
lich war. 

Es folgt in einem zweiten Schritt nun die Initialisierung 
der Koramunikationskanale zwischen den Objekten, die 
nach der gleichen Systematik wie die Erzeugung der Struk- 
tur der Software ablauft. Es werden dabei fur das Applikati- 
onsobjekt und jedes Prozess-, Thread- und Modulobjekt zu- 
mindest logische Kommunikationskanale definiert, uber die 
es mit bereits erzeugten Objekten kommunizieren kann. Da- 
bei kann ein Kommunikationskanal auch wieder als ein Ob- 



jekt angesehen werden. Zur Erzeugung der Kommunikati- 
onskanale ist bereits in dem Applikationsobjekt, den Pro- 
zess-, Thread- und Modulobjekten gespeichert, mit welchen 
weiteren Objekten Nachrichten auszutauschen sind. Zu die- 

5 sen Objekten werden dann Kommunikationskanale erzeugt. 
Nachdem die Struktur und die Kommunikationskanale 
synchronisiert erzeugt wurden, erfolgt die synchronisierte 
Initialisierung der Applikation beispielsweise mit Startwer- 
ten oder einstellbaren Parametem. Dies erfolgt nach der 

to gleichen Systematik, wie fur den ersten Schritt bereits be- 
schrieben. 

Zum Abschluss des synchronisierten Hochlaufs wird al- 
ien Objekten der Ubergang in den Normalbetrieb nach die- 
sem Schema signalisiert. Auch dies erfolgt nach der glei- 

15 chen, bereits oben beschriebenen Systematik. 

Es ist fur den Fachmann offensichtlich, dass die Auftei- 
lung der Informationen auf eine oder mehrere Dateien belie- 
big erfolgen kann. Es besteht die Moglichkeit die benotigten 
Informationen in nur wenigen Dateien abzuspeichern. So 

20 kann beispielsweise das Startprogramm bereits weitgehende 
Informationen uber die gesamte zu erzeugende Struktur be- 
inhalten. Altemativ konnen auch viele kleinere Dateien vor- 
gesehen werden, die jeweils nur einen kleinen Teil der beno- 
tigten Information fur die Initialisierung beinhalten. Weiter- 

25 hin konnen beim synchronisierten Hochlauf zusatzlich zur 
Erzeugung der Struktur, der Kommunikationskanale, der In- 
itialisierung und dem Ubergang in den Normalbetrieb noch 
weitere Schritte durchlaufen werden, insbesondere abhangig 
von der durch die Applikation zu steuernden Werkzeugma- 

30 schine. 

Insgesamt lasst sich der Hochlauf wie folgt zusammen- 
fassen. Um eine einfache Wartbarkeit und Erweiterbarkeit 
sicherzustellen, weisen die Programme fur numerische 
Steuerungen zunehmend eine objektorientierte Struktur auf. 

35 Dabei werden Applikationen, Prozesse, Threads und Mo- 
dule jeweils durch ein Objekt reprasentiert. Bei einem 
Hochlauf werden zunachst diejenigen Objekte erzeugt, die 
weitere Objekte erzeugen, und es nimmt jedes Objekt eine 
Anzahl definierter Zustande an. Insbesondere starlet jedes 

40 Objekt bei alien von ihm erzeugten Objekten jede durch das 
jeweilige Objekt realisierte Initialisierungsfunktion und 
nimmt den nachsten detinierten Zustand dann an, wenn es 
selbst und alle von ihm erzeugten Objekte samtliche Funk- 
tionen vollstandig ausgefiihrt haben. Dieser Zustand wird an 

45 das erzeugende Objekt gemeldet, bis diese Ruckmeldung 
beim Applikationsobjekt eintrifft. Das Applikationsobjekt 
nimmt dann selbst diesen Zustand an und lost den nachsten 
Schritt des Hochlaufs aus bzw. beendet den Hochlauf, nach- 
dem der letzte Schritt des Hochlaufs ausgefiihrt wurde. 

50 

Patentanspriiche 

1. Verfahren zum synchronisierten Hochlauf einer 
Applikation, insbesondere fur eine numerische Steue- 
55 rung einer Werkzeugmaschine oder eines Roboters, bei 
dem einzelne Initialisierungsschritte, bei denen gleich- 
artige Massnahmen zur Initialisierung der Applikation 
durchgefuhrt werden, in der gesamten Applikation im 
wesentlichen zeitlich synchron ausgefiihrt werden. 
60 2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass zunachst ein Startprogramm ausgefiihrt wird, 
das Informationen uber die Applikation und uber die 
zeidiche Reihenfolge der einzelnen Initialisierungs- 
schritte beinhaltet und das zumindest einen Teil der Da- 
65 ten der Applikation von einem Massenspeicher (1) in 
einen Arbeitsspeicher (4) ladL 
3. Verfahren nach einem der Anspriiche 1 oder 2, da- 
durch gekennzeichnet, dass in einem Initialisierungs- 



60 
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schritt in alien Objekten gleichartige aber nicht zwin- 
gend identische Massnahmen zur Initialisierung durch- 
gcfuhrt werden und dass in aufeinanderfolgenden In- 
ilialisierungsschritten ungleicharlige Massnahmen zur 
Initialisierung durchgefuhrt werden. 5 

4. Verfahren nach einem der Anspriiche 1 bis 3, da- 
durch gekennzeichnet, dass die in einem Iniualisie- 
rungsschritt durchzufuhrenden Massnahmen in dem 
Programmteil oder Objekt gespeichert sind, auf das sie 
auch angewendet werden. 10 

5. Verfahren nach einem der Anspriiche 1 bis 4, da- 
durch gekennzeichnet, dass die Ausfuhrung eines In- 
itialisierungsschritts in einem Programmteil oder in ei- 
nem Objekt bei einer Applikation von einem Startpro- 
gramm und sonst von dem jeweils hierarchisch iiberge- 15 
ordneten Objekt veranlasst wird. 

6. Verfahren nach einem der Anspriiche 1 bis 5, da- 
durch gekennzeichnet, dass nach der korrekten Durch- 
fuhrung eines Initialisierungsschritts in einem Objekt 
und nach dem Empfang der Ausfuhrungsmeldungen 20 
von alien dem jeweiligen Objekt zugeordneten Objek- 
ten, dieses Objekt an das hierarchisch ubergeordnete 
Objekt eine Ausfiihrungsmeldung weiterleitet. 

7. Verfahren nach einem der Anspriiche 1 bis 6, da- 
durch gekennzeichnet, dass das Startprogramm oder 25 
die Applikation den nachsten Iniualisierungsschritt erst 
startet, nachdem es von alien Applikationsobjekten 
oder Prozessobjekten eine Ausfiihrungsmeldung emp- 
fangen hat. 

8. Verfahren nach einem der Anspriiche 1 bis 7, da- 30 
durch gekennzeichnet, dass in einem Iniualisierungs- 
schritt einzelne, im wesentlichen abgeschlossene Funk- 
tionen der Applikation in Form von Objekten erzeugt 
werden. 

9. Verfahren nach einem der Anspriiche 1 bis 8, da- 35 
durch gekennzeichnet, dass in einem Iniualisierungs- 
schritt Kommunikauonskanale zwischen Objekten der 
Applikation erzeugt werden. 

10. Verfahren nach einem der Anspriiche 1 bis 9, da- 
durch gekennzeichnet, dass in einem Initialisierungs- 40 
schritt den Variablen in den einzelnen Objekten Para- 
meter zugewiesen werden. 

11. Verfahren nach einem der Anspriiche 1 bis 10, da- 
durch gekennzeichnet, dass in einem Iniualisierungs- 
schritt der regulare Betrieb der Applikation freigege- 45 
ben wird. 
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